1. Technological Field
The disclosure relates generally to the field of networking and content delivery. In one exemplary aspect, the disclosure relates to the use of a network architecture for centralized message exchange via apparatus disposed on a user premises (e.g., residence, enterprise, etc.).
2. Description of Related Technology
The provision of content to a plurality of subscribers in a network is well known. In a typical configuration, the content is distributed to the subscribers' devices over any number of different topologies including for example: (i) Hybrid Fiber Coaxial (HFC) network, which may include e.g., dense wave division multiplexed (DWDM) optical portions, coaxial cable portions, and other types of bearer media; (ii) satellite network (e.g., from an orbital entity to a user's STB via a satellite dish); (iii) optical fiber distribution networks such as e.g., “Fiber to the X” or FTTx (which may include for example FTTH, FTTC, FTTN, and FTTB variants thereof); (iv) Hybrid Fiber/copper or “HFCu” networks (e.g., a fiber-optic distribution network, with node or last-mile delivery being over installed POTS/PSTN phone wiring or CAT-5 cabling); (v) microwave/millimeter wave systems; etc.
Various types of content delivery mechanisms are utilized in providing content to subscribers. For example, certain content may be provided in accordance with “push” technology where a content server “pushes” unsolicited or asynchronous information out to specific client devices. Push services may be based on information preferences expressed in advance. In a publish-subscribe model, a client device “subscribes” to various information “channels” provided by the content server; whenever new content is available on one of those channels, the server pushes the information out to the client device. Examples of content delivery services that use push technology include instant messaging applications, video streaming services, Emergency Alert System (EAS), market data distribution services (e.g., stock tickers), sports results distribution services, home monitoring applications, and home device control applications.
A content server can push data to a client device over a full-duplex connection. For example, a web server can push information to a web server via a Transmission Control Protocol (TCP) connection. In U.S. cable systems, for instance, out-of-band (OOB) channels (and associated protocols) may be used to deliver asynchronous messages (e.g., global software updates, EAS notification, service entitlement distribution) to a subscriber device, as well as to provide communication between the headend of the content-distribution network and the subscriber device.
The content server communicates with each client device over a dedicated connection. In some cases (e.g., instant messaging sessions, video streaming sessions), the content server does not terminate the connection after the data has been transmitted to the client device. The content server leaves the connection open so that if an event occurs for reporting data to the client device, the content server can send the data to the client device immediately. In other cases, the connection is kept open through a series of periodic messages, termed “keep-alive” (KA) or “heartbeat” messages, that are sent from the client device to the content server to indicate that the client device is ready to receive data, and that the connection should be preserved. Because many centralized server systems are distributed computing structures fronted by e.g., a Global Server Load Balancer (GSLB) and a security firewall, a high cost is associated with maintaining hundreds of thousands or even millions of connections.
In scenarios where a one-time message is broadcast to multiple clients (e.g., in the aforementioned publish-subscribe model), a content server must send a message to each client device registered to receive the message from the content server. One example of a broadcast message is an EAS message. An EAS message may be targeted at a small geographic area (e.g., in the case of a storm), or to a large geographic area (e.g., in the case of a nuclear attack). The EAS server may provide the EAS notification to client devices via unicast mechanisms (i.e., each client device receives an individual copy of the message). As such, delivery of EAS messages to millions or hundreds of millions of client devices would be greatly bandwidth-inefficient and take considerable amounts of processing power. Further, typical content delivery networks may not have sufficient bandwidth capacity to support unicast delivery of EAS messages to a large number of client devices, whether due to “core” infrastructure, “edge” infrastructure, third-party infrastructure, or combinations of the foregoing. Although, some network topologies and architectures have a more efficient “multicast” capability which more effectively uses available bandwidth, most Internet Protocol (IP)-enabled client devices (and even some network infrastructure) do not support such multicast, and hence networks are relegated to use of the less efficient unicast or similar mechanism for delivery of broadcast messages.
The foregoing inefficiencies can be even more pronounced when multiple clients are each trying to communicate with entities or processes within the core portion of a network; e.g., the headend, or via “backbone” or other common core infrastructure.
In some home monitoring and home device control applications, each premises device is in communication with a centralized server—which is remote to the home. When a first premises device needs to be informed of a change of state of a second premises device, the second premises device communicates the state change to the centralized server, and the centralized server pushes a message to the first premises device notifying it of the state change of the second premises device. For example, when a remote control application with a graphic display needs to be informed of a change of state within a display device, the display device (or process relating thereto) would typically cause communication of the instruction to a remote central messaging server, which would then send a message using push technology to the remote control. As the messaging server may be thousands of miles from the home and encumbered by multiple network and switching delays, the delay between the changing of the display device and the notification on the remote control may cause the user to perform multiple button presses, and accordingly be annoyed by the lack of responsiveness of the system.
Hence, it would be desirable to provide mechanisms for exchanging messages between a content provider and a user premises device that more effectively uses communications bandwidth and processing power. It would also be desirable to provide mechanisms for exchanging messages within a user premises that provides less latency and more responsiveness than mechanisms that require repetitive transmissions to/from a central server.